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requested in view of the Amendments and Remarks below. 

Amendments to the Claims begin on page 2 of this paper. 

Remarks begin on page 9 of this paper. 



Response to Office Action 



Dear Sir: 
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Amendments to the Claims 

Kindly amend claims 1-3, 6, 8-10, 13, 15-17 & 20, as set forth below. All pending 
claims are reproduced below, with changes in the amended claims shown by underlining (for 
added matter) and double brackets (for deleted matter). 

1 . (Currently Amended) A method of assessing a product development management 
effort comprising: 

identifying muhiple possible root causes of trouble for a product 
development management effort, the product development management effort 
being undertaken to produce a tangible product; 

identifying multiple questions sets for diagnosing the muhiple possible 
root causes of trouble, each question set being a comprehensive set of questions 
directed to diagnosing a respective root cause of trouble of the muhiple possible 
root causes of trouble and identifying specific project role(s) to provide responses 
to questions of the question set, the responses from the specific project role(s) 
facilitating diagnosing the respective root cause of trouble and thus assessing the 
product development management effort to produce the tangible product, wherein 
different specific project roles are identified to provide responses to questions of 
different questions sets of the muhiple question sets; 

providing a computer-implemented tool to evaluate answers to the 
question sets and provide guidance based on scored questions regarding existence 
of one or more root causes of trouble for the product development effort from the 
identified muhiple possible root causes of trouble, the scored questions being 
produced by an automated scoring mechanism, the automated scoring mechanism 
automatically counting the number of responses in required fields of a question 
set of the muhiple question sets and scoring the question set against a total 
number of required fields in the question set to produce a numeric value which is 
an [[automatic]] indication of the strength of responses for the question set, the 
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strength of responses indication being an [[automatic]] indication of the strength 
of [[analysis]] evidence of the respective root cause of trouble and representing 
the impact of the respective root cause of trouble[[,]]; 

wherein the computer-implemented tool further produces a numeric value 
[[and]] representing the impact of the respective root cause of trouble on the 
project development management effort; and 

wherein the computer-implemented tool plots each root cause of trouble of 
the multiple possible root causes of trouble using the produced numeric values in 
a graph with a first axis representing strength of [[responses]] evidence for the 
respective root causes of trouble and a second axis representing impact of the 
respective root causes on the product development management effort, the graph 
facilitating assessing the product development management effort by facilitating 
identifying a possible root cause of trouble of the multiple possible root causes of 
trouble with a high impact on the product development management effort and 
strong [[responses]] evidence in support of the presence of the root cause of 
trouble. 

2. (Currently Amended) The method of claim 1, further comprising evaluating 
project management processes employed for the product development management effort by 
comparison thereof to identified, standard project management processes, and wherein the 
computer-implemented tool provides guidance regarding effectiveness of implementation of the 
project management processes employed for the product development management effort. 

3. (Currently Amended) The method of claim 2, further comprising evaluating 
project management work product of the product development management effort and inputting 
work product assessment to the computer-implemented tool as further evidence of the existence 
of the one or more root causes of trouble for the product development management effort or the 
effectiveness of implementation of the project management processes employed for the product 
development project. 
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4. (Previously Canceled). 

5. (Previously Presented) The method of claim 1, further comprising identifying in 
the computer-implemented tool the specific project personnel roles to answer questions of the 
multiple question sets, wherein the multiple question sets also reside in the computer- 
implemented tool. 

6. (Currently Amended) The method of claim 1, wherein the product development 
management effort comprises one of a management effort for a software development project or 
a management effort for a hardware development project. 

7. (Previously Canceled). 

8. (Currently Amended) A system for assessing management of a product 
development project comprising: 

a processor comprising a computer-implemented tool identifying multiple 
common root causes of trouble for a product development management effort 
undertaken to produce a tangible product and multiple question sets for 
diagnosing the multiple common root causes of trouble, each question set being a 
comprehensive set of questions directed to diagnosing a respective root case of 
trouble of the multiple possible root causes of trouble and identifying specific 
project role(s) to provide responses to questions of the question set, the responses 
from the specific product role(s) facilitating diagnosing the respective root cause 
of trouble and thus assessing the product development management effort to 
produce the tangible product, wherein different specific project roles are 
identified to provide responses to questions of different questions sets of the 
multiple question sets, and wherein the computer-implemented tool evaluates 
answers to the question sets and provides guidance based on scored questions 
regarding existence of one or more root causes of trouble for the product 
development management effort from the identified multiple common root causes 
of trouble, the scored questions being produced by an automated scoring 
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mechanism, the automated scoring mechanism automatically counting the number 
of responses in required fields of a question set of the multiple question sets and 
scoring the question set against a total number of required fields in the question 
set to produce a numeric value which is an [[automatic]] indication of the strength 
of responses for the question set, the strength of responses indication being an 
[[automatic]] indication of the strength of [[analysis]] evidence of the respective 
root cause of trouble[[,]]; 

wherein the computer-implemented tool further produces a numeric value 
[[and]] representing the impact of the respective root cause of trouble on the 
project development management effort; and 

wherein the computer-implemented tool plots each root cause of trouble of 
the multiple possible root causes of trouble using the produced numeric values in 
a graph with a first axis representing strength of [[responses]] evidence for the 
respective root causes of trouble and a second axis representing impact of the 
respective root causes on the product development management effort, the graph 
facilitating assessing the product development management effort by facilitating 
identifying a possible root cause of trouble of the multiple possible root causes of 
trouble with a high impact on the product development management effort and 
strong [[responses]] evidence in support of the presence of the root cause of 
trouble. 

9. (Currently Amended) The system of claim 8, wherein the computer-implemented 
tool further comprises means for evaluating project management processes employed for the 
product development management effort by comparison thereof to identified, standard project 
management processes, and wherein the computer-implemented tool provides guidance 
regarding effectiveness of implementation of the project management processes employed for 
the product development management effort. 
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10. (Currently Amended) The system of claim 9, wherein the computer-implemented 
tool further comprises means for evaluating project management work product of the product 
development management effort as fiirther evidence of the existence of one or more root causes 
of trouble for the product development management effort or the effectiveness of implementation 
of the project management processes employed for the product development management effort. 

1 1 . (Previously Canceled). 

12. (Previously Presented) The system of claim 8, wherein the computer- 
implemented tool further comprises means for identifying the specific project personnel roles to 
answer questions of the multiple question sets, wherein the multiple question sets also reside 
within the computer-implemented tool. 

13. (Currently Amended) The system of claim 8, wherein the product development 
management effort comprises one of a management effort for a software development project or 
a management effort for a hardware development project. 

14. (Previously Canceled). 

15. (Currently Amended) At least one program storage device readable by a 
computer embodying at least one program of instructions executable by the computer to perform, 
when executing on the computer, a method of assessing a product development management 
effort, the method comprising: 

identifying multiple possible root causes of trouble for a product 
development management effort, the product development management effort 
being undertaken to product a tangible product; 

identifying multiple question sets for diagnosing the multiple possible root 
causes of trouble, each question set being a set of comprehensive questions 
directed to diagnosing a respective root cause of trouble of the multiple possible 
root causes of trouble and identifying specific project role(s) to provide responses 
to questions of the question set, the responses from the specific project role(s) 
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facilitating diagnosing the respective root cause of trouble and thus assessing the 
product development management effort to produce the tangible product, wherein 
different specific project roles are identified to provide responses to questions of 
different questions sets of the multiple question sets; 

evaluating answers to the question sets and providing guidance based on 
scored questions regarding existence of one or more root causes of trouble for the 
product development effort from the identified multiple possible root causes of 
trouble, the scored questions being produced by an automated scoring mechanism, 
the automated scoring mechanism automatically counting the number of 
responses in required fields of a question set of the multiple question sets and 
scoring the question set against a total number of required fields in the question 
set to produce a numeric value which is an [[automatic]] indication of the strength 
of responses for the question set, the strength of responses indication being an 
[[automatic]] indication of the strength of [[analysis]] evidence of the respective 
root cause of trouble; 

wherein the computer-implemented tool fiirther produces a numeric value 
[[and]] representing the impact of the respective root cause of trouble on the 
project development management effort; and 

wherein the computer-implemented tool plots each root cause of trouble of 
the multiple possible root causes of trouble using the produced numeric values in 
a graph with a first axis representing strength of [[responses]] evidence for the 
respective root causes of trouble and a second axis representing impact of the 
respective root causes on the product development management effort, the graph 
facilitating accessing the product development management effort by facilitating 
identifying a possible root cause of trouble of the multiple possible root causes of 
trouble with a high impact on the product development management effort and 
strong [[responses]] evidence in support of the presence of the root cause of 
trouble. 
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16. (Currently Amended) The at least one program storage device of claim 15, 
wherein the method further comprises evaluating project management processes employed for 
the product development management effort by comparison thereof to identified, standard 
project management processes, and providing guidance regarding effectiveness of 
implementation of the project management processes employed for the product development 
management effort. 

17. (Currently Amended) The at least one program storage device of claim 16, 
wherein the method further comprises evaluating project management work product of the 
product development management effort and providing work product assessment as further 
evidence of the existence one or more root causes of trouble for the product development 
management effort or the effectiveness of implementation of the project management processes 
employed for the product development management effort. 

18. (Previously Canceled). 

19. (Previously Canceled). 

20. (Currently Amended) The at least one program storage device of claim 15, 
wherein the product development management effort comprises one of a management effort for a 
software development project or a management effort for a hardware development project. 
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Remarks 

Allowance of the claims presented herewith is respectfully requested. Claims 1-3, 5, 6, 

8-10, 12, 13, 15-17 & 20 remain pending. 

By this paper, independent claims 1, 8 & 15 are amended to more clearly point out and 
distinctly claim certain aspects of the present invention. In particular, these claims are amended 
to specify that the computer-implemented tool produces a numeric value which is an indication 
of the strength of evidence of the respective root cause of trouble, and additionally produces a 
separate numeric value which is representative of the impact of the respective root cause of 
trouble on the product development effort. Additionally, Applicants' independent claims are 
amended to specify that the recited protocol is for evaluating a product development 
management effort. Support for the amended claim language can be found throughout the 
application as filed. For example, reference specification paragraphs [0052] - [0070], as well as 
FIG. 4A of the application. No new matter is added to the application by any amendment 
presented. 

Initially, claims 1-3, 5, 6, 8-10, 12, 13, 15-17 & 20 were rejected under 35 U.S.C. § 1 12, 
second paragraph, as being indefinite for failure to particularly point out and distinctly claim the 
subject matter which Applicants regard as the invention. Responsive to this rejection. Applicants 
have herein amended independent claims 1, 8 & 15 to separately call out the strength of evidence 
numeric value and the impact numeric value ascertained by the tool for the respective root causes 
of trouble. These two variables are then employed in a graphical plot as recited in the 
independent claims. In view of these amendments, reconsideration and withdrawal of the 35 
U.S.C. § 112, second paragraph, rejection is respectfully requested. 

In the Office Action, claims 1-3, 5, 6, 8-10, 12, 13, 15-17 & 20 were rejected under 35 
u s e. § 103(a) as being unpatentable over Whitacre et al. (U.S. Patent PubUcation No. 
2004/0138944; hereinafter Whitacre), also evidenced by Whitacre et al. Provisional Application 
filed July 22, 2002, pages 1-76 (hereinafter Provisional), in view of Miller (U.S. Patent 
Publication No. 2002/0165752; hereinafter Miller), further in view of Applicants' Admitted Prior 
Art (hereinafter AAPA), fiirther in view of Nelson (U.S. Patent No. 7,451,063; hereinafter 
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Nelson). This rejection is respectfully traversed to any extent deemed applicable to the claims 
presented herewith, and reconsideration thereof is requested. 

Independent claims 1, 8 & 15 are amended, in part, to emphasize that Applicants' 
protocol is for assessing a product development management effort undertaken to produce a 
tangible product. The Office Action recognizes at page 8, paragraph 2 that Whitacre in view of 
Miller in view of AAPA does not explicitly teach that the project or management effort is 
undertaken to produce a tangible product. Applicants agree. However, the Office Action 
concludes that this aspect of Applicants' invention is taught by Nelson. This conclusion is 
respectfully traversed. 

As recited in the claims presented herewith. Applicants claim a protocol for assessing a 
product development management effort. In accordance with Applicants' invention, root causes 
of trouble are identified that hinder or may hinder the product development management effort. 
In contrast. Nelson deals entirely with Failure Mode Detection Analysis, which is a quality 
control procedure used in Operations Management. FDMA and FMEA (Failure Mode and 
Effects Analysis) analyze product failure modes (or failure modes in the processes that create the 
products) in order to prioritize where to focus improvement efforts (see, for example. Nelson 
column 1, lines 40-48). Thus, Nelson is directed to improving product quality. While Nelson's 
FDMA approach might be employed in a product development effort to ensure that the product 
is being produced with minimal critical failure modes. Applicants' claimed invention is used to 
identify root cause of trouble in the project management of that effort. Thus, Applicants' 
invention aims to correct the root cause of trouble of the product development management 
effort, meaning correct any failed management of the project, but does not relate to correcting 
failure modes in the product design or manufacturing process itself The most smoothly 
managed project might produce a product with several critical failure modes, and thus the need 
for Nelson. Applicants' invention, on the other hand, operates at a higher (i.e., managerial) level 
in the product development effort. Most significantly. Applicants respectfully submit that there 
is no motivation to modify the product quality control technique of Nelson when attempting to 
identify and correct root cause of trouble in the management of a product development effort. 
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For at least this reason, the claims presented are believed to patentably distinguish over the 
applied and known art. 

In Applicants' invention, a protocol is recited for identifying multiple possible root 
causes of trouble for the product development management effort. Specifically, Applicants 
specify in their independent claims identifying specific project role(s) to provide responses to 
questions of the question set. Since Applicants are troubleshooting a product development 
management effort, it is necessary to identify the specific project roles for providing the best 
responses to questions of the question set. Thus, the protocol recited explicitly sets forth 
processing directed to Applicants' assessment of the product development management effort, in 
order to identify root causes of trouble within such a management effort. 

Additionally, Applicants specify that the responses from the specific project role(s) 
facilitate diagnosing the respective root cause of trouble, and thus assessing of the project 
development management effort to produce the tangible product, and further that different 
specific project roles are identified to provide responses to questions of different question sets of 
the multiple question sets. In accordance with Applicants' recited protocol, multiple specific 
project roles are identified for providing responses to different questions of different question 
sets of the multiple question sets identified for diagnosing the multiple possible root causes of 
trouble of the product development management effort. These characterizations are believed to 
patentably distinguish Applicants' protocol over the applied and known teachings. 

Again, Applicants' independent claims recite identifying specific project role (s) to 
provide responses to questions of the question set. This identifying is performed for each 
question set of the multiple question sets identified for diagnosing the multiple possible root 
cause of trouble. Cited against this aspect of Applicants' invention are the teachings of Nelson, 
and in particular, the recognition that both design and process FMD As can be conducted using 
design engineers and process engineers. In particular, the risk factor number is asked for and 
responded to by the team of engineers specific to the process or product design. The 
applicability of this teaching to Applicants' recited invention is respectfully traversed. 

Before discussing Nelson, however, Whitacre is briefly addressed. As previously noted, 
Whitacre does not identify project roles or key personnel as defined in Applicants' invention to 
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whom questions should be asked. A careful reading of Whitacre fails to uncover any teaching or 
suggestion of tailoring an individual's questions based on their role as related to each possible 
root cause of trouble, let alone specifically identifying those roles based on the particular 
question set at issue. This aspect of Applicants' invention is significant from a resource 
expenditure standpoint, and ensures that the best information is received from the most reliable 
sources. Moreover, the proper roles to be included in the assessment may well encompass roles 
that are not directly affected by the outcome of the actions to be taken, contrary to the 
suggestions of Whitacre. 

Nelson is equally unspecific when applied against this aspect of Applicants' invention. 
Nelson teaches involving design engineers or process engineers depending upon whether a 
design FDMA or process FDMA is being conducted, again, on the product, as opposed to the 
management process to which the present invention is directed. Further, Nelson is limiting in 
that it involves only design engineers, as opposed, for example to managers, manufacturers, 
customers, etc., all of whom may be involved in the product development. For example, 
engineers, while possessing technical knowledge, may be ill-suited to fiiUy assess potential 
breakdowns in a design or process management effort. Nelson's teaching of using only "an 
engineer working with the process" (see column 1 8, lines 1 5-1 6) to conduct an FDMA review 
teaches away from Applicants' invention in that it does not contemplate an intelligent decision 
identifying specific project roles to provide responses to questions of specific question sets 
created to diagnose respective root causes of trouble, as recited by Applicants. Further, 
Applicants' independent claims recite that different specific project roles are identified to 
provide responses to questions of different question sets of the multiple question sets. No such 
teaching is provided by Nelson, or the other art of record. Again, Nelson teaches that the 
engineer working on the process is to answer the questions. This makes sense when trouble 
shooting a product using FDMA (to which Nelson is directed), but is not practical when 
evaluating the product development management effort (as claimed by Applicants). For these 
additional reasons, Applicants respectfully submit that the independent claims presented 
patentably distinguish over the teaching of the applied and known art. 
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In addition, as amended Applicants' independent claims recite that the computer- 
implemented tool produces a numeric value which is an indication of the strength of responses 
for the question set, and represents the strength of evidence of the responses. Applicants' 
strength of evidence numeric value can be thought of as a validation or negation of responses to 
the questions asked. This recited process compares the number of required fields answered in 
the affirmative to the total number of required fields, and uses this in an algorithm that ultimately 
produces an indication about whether the document contains data that supports or negates the 
possibility of a root cause of trouble. Cited against this aspect of Applicants' invention is Miller. 
Miller addresses administering tests to job applicants and teaches, in paragraph [0247] 
identifying a percentage of acquired questions answered correctly (see also paragraph [0074] of 
Miller). Applicants respectfully submit that this teaching has nothing to do with their recited 
invention. Miller discusses ordinary scoring of a test. In contrast. Applicants recite determining 
a numeric value which is representative of strength of evidence, which either supports or rejects, 
e.g., via examination of work product of a project, the presence of a potential management 
problem in the project's development. See in this regard FIG. 3C of Applicants' application 
which provides some areas of potential problem and numeric values indicating an assessment of 
whether the work product supports or negates an assessment of a problem with those areas. 

Analogizing the teachings of Miller to Applicants' recited invention is also believed 
improper since Miller focuses on identifying whether candidates answers questions (mandatory 
or not) correctly or incorrectly. Miller's required questions are ones that all applicants should 
answer so as to objectively rank the applicants according to how correctly they answer those 
mandatory questions. In contrast. Applicants' recited required fields, support or negate an 
answer to a question of the selected question set. In other words, the required fields in 
Applicants' invention are points of validation of an answer to a question, to verify that there is 
strength of evidence in the answer given. In contrast. Miller does not require validation of 
applicant answers, per se. They are either correctly answered or incorrectly answered. In Miller, 
an applicant could answer questions about his character, and we might make a conclusion based 
on those answers. However, there is no validation of strength or accuracy of the answer. This is 
contrasted with Applicants' recited invention. By way of example, in Applicants' invention 
there might be an inquiry as to whether deliverables for a project are well defined (see FIG. 3C 



END920030113US1 



-13- 



PROPOSED AMENDMENT 



"deliverable definition"). The project manager might first ask questions to employees to illicit 
fi-om them whether they believe deliverables have been well defined. Employees might assert 
that deliverables have been defined well, and then the project reviewer examines, for instance, 
documents distributed to employees that purport to define the deliverables. In accordance with 
Applicants' invention, certain "required fields" might be expected to appear in those documents 
given to the employees, in the sense that if these fields are present or not present in the 
documents, indicates that deliverables have or have not been well defined to the employees. 
Examples of a required field may include (i) to whom the deliverable should be submitted, and 
(ii) the required timeframe for submission. Assuming that employees receive documentation 
with 90% of the required fields, it indicates strongly that their responses can be held valid, and 
that deliverables have in fact been well defined. For this reason. Applicants respectfully submit 
that there is no analogous teaching of a computer-implemented tool which produces a numeric 
value representative of strength of evidence of the responses given to the different question sets, 
as recited in their independent claims. As such, the claims presented herewith are believed to 
patentably distinguish over the applied and known art. 

Applicants' computer-implemented tool further plots each root cause of trouble of the 
multiple possible root causes of trouble using the produced numeric values for strength of 
evidence versus the numeric values for impact of the root causes of trouble on the product 
development management effort. In Applicant's recited invention, the graph facilitates assessing 
the product development management effort by facilitating and identifying a possible root cause 
of trouble of the multiple possible root causes of trouble with high impact on the product 
development management effort, and strong responses in support of the presence of that root 
cause of trouble. 

The above-noted features of Applicants' invention provide numerous advantages. For 
example, evaluating the graph produced provides a basis for recommendations for remedy of a 
disclosed product development management deficiency. The graph highlights problems and 
allows problem solvers to quickly identify root causes that have significant negative impact on 
the project management and have strong evidence for support. The graph recited also facilitates 
quick elimination of those issues that have low or no negative impact on the project 
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management, and eliminates issues that are not supported by evidence. The above-noted aspects 
of Applicants' independent claims patentably distinguish Applicants' protocol over the teachings 
of the applied and known art. In Whitacre, a chart is generated that compares an individual 
worker's performance against standard performance and his co-workers (see paragraph [0096] of 
Whitacre). In FIG. 4, one pie chart represents the performance of an individual worker, while 
the other pie chart represents performance of the entire team. There is no teaching or suggestion 
that the graphs depicted in Whitacre in any way relate to how particular root causes of trouble 
impact or affect an individual's performance. Thus, the charts of Whitacre do not assist team 
leaders in identifying root causes of trouble that have significant impact on the individual 
performance, nor do the charts suggest potential causes that are most likely to have the greatest 
impact on the individual's performance. Since the Provisional, Miller, AAPA and Nelson 
documents also do not teach the above-noted deficiencies when applied against Applicants' 
protocol, it is respectfully submitted that the independent claims presented patentably distinguish 
over the applied and known art. 

For at least the above-noted reasons. Applicants respectfully submit that the independent 
claims presented herewith are patentable. The dependent claims are believed allowable for the 
same reasons as the independent claims, as well as for their own additional characterizations. 

Should any issue remain unresolved, however. Applicants ' undersigned representative 
requests a telephone interview with the Examiner to further discuss the matter in the hope of 
advancing prosecution of the subject application. 

Respectfully submitted, 



Kevin P. Radigan, Esq. 
Attorney for Applicants 
Registration No.: 31,789 

Dated: September ,2009. 

HESLIN ROTHENBERG FARLEY & MESITI P.C. 

5 Columbia Circle 

Albany, New York 12203-5160 

Telephone: (518)452-5600 

Facsimile: (518)452-5579 
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